Subject: More on Capabilities...

From: [email-masked] (Scott Adams)
Date: Wed, 14 Jul 1993 14:07:42 -0400 (EDT)

Are we (the entire SIG) trying to make the protocol described in RFC
1434 an interoperable standard, or are we trying to solve the problem
for which the protocol described in RFC 1434 is just one solution?  If
the answer is the former, then shouldn't we proceed on the assumtion
that we are trying to fit into DLS (as described by RFC 1434) a
(simple) means of exchanging information between DLSwitches about what
they can do?  If what we are trying to do is the latter, then we are
in effect re-designing the entire protocol (by committee), and we'll
have a huge, ugly mess sometime in 1995.  If we don't agree on the
answer to the question, then we will never reach a concensus on how to
do capabilities exchange, or what that means.

Personally, I want to produce a product real soon now, and though I
feel that in some small way my personal integrity is diminished by
supporting only an adequate solution to a problem, rather than finding
a very good solution, I will live with it.  Enough about that stuff...

Specific Suggestion:

 o  Use the TCP connections (or any other connection-oriented
    transport) established for tunneling to pass capabilities, and do
    it in a new packet type (say, for argument, pkt type 0x7f).
    Capabilities, I'm assuming, are only exchanged when two DLSw`s
    first contact each other, so why mix the code for processing
    capabilities into that for processing headers in other packet
    types?

 o  Use tag/length type records within the packet to pass capabilities
    (boolean, values, etc.).  Define tags for anything that might be
    optional (accept DLSw id's, loop prevention, full-duplex TP
    connection usage, dynamic TP connections, etc.) and for values
    that might need to be exchanged (such as initial pacing windows,
    number of LLC cnxn over a TP cnxn, etc.).  Our proposal would
    define all the tags/lengths/formats we can identify, and define
    process for extension.

 o  Consider Base functionality as: A> The establishment of a
    "tunnel" between two DLSwitches (now defined as two simplex TCP
    connections), B> the exchange of "Capability Exchange" SSP pkts,
    C> the ability to receive all SSP packets without "breaking" the
    tunnel (don't actually have to support NETBIOS SSP packets, or
    even the SNA SSP packets, but just don't establish such cnxns), D>
    if connections (LLC 2 cnxns) are established, then support some
    base form of flow control across SSP (as per defined by the flow
    control working group, probably the ability to back-pressure a
    source end-station via RNR's as a result of RNR's from the
    destination).

 o  I don't think that a vendor id is a good idea, especially if it is
    mandatory in an exchange packet.  I don't want to encourage
    private variations on DLS, as I think this could greatly
    complicate interoperability.  If the protocol doesn't solve a
    problem, then a suggestion should be made to fix the protocol.

These are my opinions/suggestions; what do the rest of you think?

Scott

---

From: [email-masked] (David Matusow)
Date: Wed, 14 Jul 93 17:02:07 -0400

>   From: [email-masked] (Scott Adams)
>   Subject: More on Capabilities...
>   To: [email-masked]
>   Date: Wed, 14 Jul 1993 14:07:42 -0400 (EDT)

First, I would agree with Scott that we need to address the 
interoperability of DLS switches, not the larger question of
interoperating routers in general.

>       capabilities into that for processing headers in other packet

I feel that the UDP method of listening to a socket for capabilities
is more condusive for this purpose, but other ways can be justified.
    
>       define all the tags/lengths/formats we can identify, and define
    
Strongly agree that a tab/length method is preferable, but let's keep
it consistent (unlike the SNA control vectors).  I vote for LLID, like
GDS; this is easier to parse apart.

This method allows unsupported vectors to be bypassed and provides a 
clean method of adding new values and tags.

>       problem, then a suggestion should be made to fix the protocol.

Inclusion of a vendor ID is good.  It doesn't stop any interoperability,
but does aid in problem determination (and customer finger-pointing).
It also provides the customer with the maximum amount of information
on the configuration.

As a former consultant and user, I know the how difficult it is to
form a network map.  As we move more and more towards dynamic network
configuration, it is more and more important to provide as much information
as possible.  Vendor name, software level, DLS support level, etc. are
minimum pieces of information.  It also opens the door for vendors to
key off this information and provide enhanced interfaces (otherwise
known as, proprietary).  There is nothing wrong with this as it
increases pressure on all of us to provide the maximum amount of
customer support.

Well, there's my 2 cents worth....

David